時間咻一下地就來到了第 30 天，在這段期間看了很多自己不熟悉的部分，也看了自己以為自己已經熟悉的部分，但卻從過程中發現到自己原來對於 Next.js 有一些誤解，所以最後這一天在發表完善感言之前，想要用「常見誤解」的部分來個回顧。
身邊不少人講到 Next.js 時，就覺得它就等於 SSR，或是認為只要使用 Next.js 就等於是在使用 SSR。但實際上 Next.js 會盡量以靜態的方式來做畫面的渲染，所以如果沒有動態的內容，或顯式設定為動態渲染時，其實 Next.js 會去使用 SSG 的方式去做畫面的渲染。所以使用 Next.js 並不等於使用 SSR，Next.js 會依照實際的使用情況去判斷是要使用 SSR、SSG 或 ISR。
就如同前面提到過的內容一樣，在聊到 Next.js 的時候，一定會聊到的內容就是 SSR。在 Next.js 中除了 SSR 之外，還有一個名稱上有點類似的元件類型，這個元件類型也就是 Server Component，也有人會將稱為 RSC (React Server Component)。由於 Server Component 這個元件類型名稱上也有一個 Server，所以偶爾會有一些人覺得 Server Component 就等於 SSR。
其實 SSR 與 Server Component 雖然名稱中都有 Server，但是它們從本質來說就是不同的東西。SSR 是一種渲染模式，而 Server Component 則是一種元件類型。雖然它們都會在 Server 上進行一些事情，但實際在 Server 上進行的事情也不同，SSR 的部分是在 Server 上預先產生出完整的 HTML，Server Component 的部分則是會在 Server 上將元件內容序列化成 RSC payload。
雖然這 SSR 和 Server Component 都是為了讓網頁效能更好的產物，但事實上兩者並不是相同的東西，而且實務上兩者可以並行存在。
有 Server Component，當然也就有 Client Component，但是 Client Component 並不只會在 Client 端執行，如果這個 Client Component 是出現在首屏，且沒有特別關閉 SSR 的渲染的話，其實一開始還在 Server 端的階段，就會先執行過一次 Client Component，預先將可以先產生成 HTML 的部分先於 Server 上產生出來，其他只能在 Client 端上進行的 hooks 和 Hydration 的部分，會在 Client 端上再進行。
也是因為這樣的緣故，如果在寫 Client Component 時，沒有記得 Client Component 會分別在 Server 端和 Client 端各別執行一次，當元件內容中，有一些可能在 Server 端和 Client 端出現不同的內容時，就有可能會在 Hydration 階段出現 mismatch 的錯誤。要記得 Client Component 這個種類的元件名稱雖然只帶有 Client 這個詞，但實際上並不是只會在 Client 端上執行。
Next.js 這個框架為了讓網頁的效能變好，除了提供 SSR 這種渲染模式和 Server Component 這種元件外。Next.js 還提供了可以優化效能的 Image 元件。使用 Image 元件時，預設會用 lazy loading 的圖片載入方式，以避免阻塞畫面的渲染。除此之外，當使用 Image 這個元件時，還會自動將圖片進行 webp 格式的轉換，以壓縮圖片的大小。這些 Image 元件提供的能力，聽起來很棒，因為自動幫我們做了圖片的優化，但是事實上並不是使用了，就一定對圖片的效能有正面的影響。
由於 Image 是一個元件，一個幫我們做很多優化動作的元件，所以當我們使用的圖片大小偏小時，還是使用 Image 的話，就有可能因為圖片可以壓縮的大小有限，但 Image 實際上為了進行圖片優化所要花費的工還是要進行的緣故，導致反而對圖片優化有負面的影響。如果首屏有大量的圖片，又沒有將圖片透過加上 priority 這個 prop 來關閉 lazy loading 的話，也有可能會導致拖慢 LCP 的問題出現。所以 Image 並不是有用就好，還需要依照情況聰明地使用。
講到 Next.js，大家一定也會想到這個框架是對於 SEO 非常有幫助的框架，但是並不是只要使用了 Next.js 就等於對 SEO 有全面的幫助，也不是只要有使用 Next.js SSR、SSG 或 ISG 就是有做 SEO。事實上在使用 Next.js 的時候，如果沒有正確使用各種會影響效能的方式，或是還在用 CSR 的思維去處理畫面渲染的話，實際上有可能對 SEO 有負面的效果。在進行 SEO 時，我們必須記得 SEO 的重點是「讓網頁的內容能被抓取、看得懂、對使用者有價值、體驗良好」。
這邊也實際回顧一些之前說過例子：
如果在使用 Next.js 時，雖然用了 SSR 這個渲染模式了，但是因為某些頁面內容是透過 API 取得，會需要一些時間才拿到資料，就自作聰明地加上 loading 標示，讓資料在 client 端取得回來前可以顯示正在取得資料，這麼做其實對於 SSR 並沒有正向的幫助。既然都已經使用了 SSR，就應該要擺脫 CSR 的思維，讓取得資料這件事盡可能地在 Server 端上進行，而不是在 Client 端上進行，這樣才能讓該被瀏覽器抓取、看懂的資訊在第一時間就能夠被抓取。
再來是如果使用 Next.js 時，沒有正確地使用 next/dynamic，這樣的話，實際上並不會對 SEO 有加分的效果。這裡的錯誤的方式指的是把 { ssr: false } 加上，讓 SSR 階段不會預先產生相對應的內容，只會進行該內容的佔位處理，也就無法讓需要在第一個時間就回傳給瀏覽器的內容出現在 Server 端回傳的 HTML 上。
雖然已經是第二次參加了，但是老實說做出再次參加的這個決定還是有點煎熬(?)。在正式開賽前的準備期到正式開賽時，更因為家中有一堆與人、與玄學有關的雜事發生，忙到焦頭爛額，也讓我一度在思考是不是這次應該要放棄參加。尤其第一次參加時陪伴我的小書僮突然離世，變成這次的我只能孤軍奮戰。雖然這段期間對我來說是有點艱難的時間，但還是很感謝自己撐下來了。
目前的我雖然在工作上主要是碰 Next.js 框架，但事實上有很多坑也是在自己實作時踩到才發現原來跟自己預想的狀況並不一樣，也意識到自己其實根本不懂 Next.js 這套框架。甚至有些比較底層的原理和概念，也是在這次參加鐵人賽的期間，才發現到字一直以來都搞錯了，但原本不懂沒關係，有趁著這次好好搞懂也還來得及。除此之外，自己在這次準備鐵人賽的過程中，除了看官方文件外，也嘗試透過看原始碼來了解框架背後做了什麼事情，另外也搭配做很多實驗，來加深自己對於 Next.js 這套框架的理解度。這些過程雖然花了很多時間，但最後獲益良多。
這次雖然是第二次參加鐵人賽，但一樣不是以什麼大大的身份去完成這三十天的挑戰，而是以一位普通人下去分享自己學習到的內容，也刻意透過這個過程逼自己維持一段長時間的深度學習。當然這次也跟上一次一樣，想要給正在轉職路上，或是剛轉職成功的人一些力量，因為我這樣普通的人都可以這樣持續地學習，並且完成這三十天的挑戰，大家一定也可以！雖然成為工程師就等於是挖坑給自己跳，因為一旦成為了工程師，就不能只維持這三十天的學習旅XD
最後感謝我的室友在我荒廢家務的這三十天幫了我很多忙，也謝謝身邊朋友的鼓勵，我才能堅持下去，完成第二次鐵人賽的挑戰。
雖然我的小書僮不在了，但最後還是分享我最愛的小書僮可愛照片 ：）
iThome鐵人賽
看影片追技術